home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 8163 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.1 KB  |  79 lines
  1. Path: monkeys.com!not-for-mail
  2. From: rfg@monkeys.com (Ronald F. Guilmette)
  3. Newsgroups: comp.lang.c,comp.lang.c++,gnu.gcc.help,gnu.g++.help,comp.os.msdos.djgpp
  4. Subject: Re: float != float and floats as return types
  5. Date: 15 Feb 1996 01:20:39 -0800
  6. Organization: Infinite Monkeys & Co.
  7. Message-ID: <4futt7$6b7@segfault.monkeys.com>
  8. References: <4ej9lb$mpc@fu-berlin.de> <4elnjj$er4@server2.rz.uni-leipzig.de> <4eqc7l$ugh@godzilla.zeta.org.au>
  9. NNTP-Posting-Host: segfault.monkeys.com
  10.  
  11. In article <4eqc7l$ugh@godzilla.zeta.org.au>,
  12. Bruce Evans <bde@zeta.org.au> wrote:
  13. >In article <4elnjj$er4@server2.rz.uni-leipzig.de>,
  14. >Steffen Winterfeldt <wfeldt@physik.uni-leipzig.de> wrote:
  15. >>Axel Thimm (axl@zedat.fu-berlin.de) wrote:
  16. >>: Hello,
  17. >>: I am getting confused, about how C/C++ manage float binary operations,
  18. >>: in particular multiplication. The next C++ example gives me surprising
  19. >>: results:
  20. >>:     *** cut here: begin file t_prec.cc
  21. >>:     #include <iostream.h>
  22. >>:     #include <iomanip.h>
  23. >>:     #include <math.h>
  24. >>:     float quad( float );
  25. >>:     int main() {
  26. >>:       for( int i=0; i<10; ++i ) {
  27. >>:         float a, b, c;
  28. >>:         a = i/13.123123;
  29. >>:         b = a*a;
  30. >>:         c = quad(a);
  31. >>:         cout << (b - c) << '\t';
  32. >>:         cout << (b - a*a) << '\t';
  33. >>:         cout << (c - quad(a)) << '\n';
  34. >>:       }
  35. >>:       return 0;
  36. >>:     }
  37. >>:     float quad( float x ) { return x*x; }
  38. >>: [...]
  39. >>
  40. >>(c - quad(a)) is not zero, because quad's return value is in a floating point
  41. >>register and so has higher precision than c.
  42. >
  43. >Wrong.
  44. >
  45. >gcc's machine description for the i386 bogusly says that the result of a
  46. >(float * float) calculation has float precision.  This is only true if
  47. >the ambient precision is 24 bits or if -msoft-float is used.  Because of
  48. >this, gcc omits the conversions that it would do if it had the correct
  49. >precision (type) information.  It clips the extra precision for
  50. >assignments from double variables or long double variables to float
  51. >variables and for returning double or long double values from functions
  52. >that return float, even if the value is originally in a floating point
  53. >register and could end up in the same register.  The ANSI standard is
  54. >ambiguous about whether these conversions must be done.
  55.  
  56. I agree that it is, however a response to an official Defect Report clearly
  57. indicated that when a float is to be returned (as the result of a function)
  58. and when the actual type of the expression appearing in a return statement
  59. in that function is some wider floating-point type, then the result gets
  60. narrowed ``as if passing through a knothole''.
  61.  
  62. > Anyway, gcc sometimes skips them...
  63.  
  64. This is a known bug in gcc/x86.
  65.  
  66. >If the ambient precision is 64 bits, as it is under Linux...
  67.  
  68. There is no such thing as an ``ambient precision''.
  69.  
  70. On x86 systems, it is generally easiest to carry out all FP operations using
  71. 80 bits (i.e. long double) and then narrow the results when required by the
  72. standard.
  73.  
  74. -- 
  75.  
  76. -- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
  77. ---- E-mail: rfg@monkeys.com ----------- Purveyors of Compiler Test Suites -
  78. ------ Copyright (c) 1996 by Ronald F. Guilmette; All rights reserved. -----
  79.